The latest major release of our favorite blogging platform – WordPress 3.0 – has brought quite a few new features to the table. Among them, the custom navigation menus and the post thumbnails (featured image), the latter being available since version 2.9 came out. This started a whole new trend between theme developers, most of them rushing to announce WordPress 3.0 ready themes.
In all this rush, some of the themes released suffered from one big problem: backward compatibility. Why is that important and how can we give some backward compatibility to our WordPress 3.0 ready themes?
Importance of backward compatibility
While I feel that generally offering some sort of backward compatibility is just a common sense policy, in this case it’s more than that. Let me explain why.
Not everyone uses the latest WordPress release, and that is for various reasons:
- Failed to update, or waiting to make sure it’s “stable”;
- Doesn’t really get the importance of an up to date software;
- Certain plugins they use are not yet 3.0/3.0.1 compatible.
This doesn’t mean they don’t want to try and use your beautiful 3.0 ready WordPress theme, or that they shouldn’t. But you see, the biggest trick resides right here, in this terminology: “3.0 ready”. The actual meaning of this is that the theme is compatible with the 3.0 version, not that it requires 3.0 or higher to function properly, and this leads a lot of people into a trap that will cause their blogs and websites to break.
So, the common sense thing to do would be to take the time and apply certain checks and fallback solutions to our themes. Lets see how we can do that.
Adding WordPress 3.0 features with fallback support
Both of the above mentioned features – custom menus and post thumbnails – are based on a WordPress function added once 2.9 was released: add theme support();
Adding post thumbnails support
In order to add post thumbnail support to your theme, you’d write this in your functions.php file:
[php]
// Adds support for post thumbnails
add_theme_support(‘post-thumbnails’);[/php]
Simple adding this will cause any WordPress installation prior to 2.9 to break, as the add_theme_support() function was not part of the WordPress core back then. The fix? As easy as this:
[php]
/* Checks if the installation has the function defined.
If true, continues to add the support for post thumbnails. */
if(function_exists(add_theme_support)) :
add_theme_support(‘post-thumbnails’);
endif;[/php]
Adding custom menus support
In order to also add support for the custom menus feature, you’d normally write this:
[php]// Add theme support for custom menus
add_theme_support( ‘menus’ );
// Register a custom menu name/location
register_nav_menus(array(
‘custom-menu’ => __( ‘My Custom Menu’ ),
));
[/php]
In this case, we obviously need to check for core support of both functions: add_theme_support() and register_nav_menus(). Let see how we can do that, also including in this check the post thumbnails:
[php]
if(function_exists(add_theme_support)) {
add_theme_support(‘post-thumbnails’); // Support for post thumbnails
if(function_exists(add_theme_support)) {
add_theme_support( ‘menus’ ); // Support for custom menus
register_nav_menus(array(
‘custom-menu’ => __( ‘My Custom Menu’ ),
));
}
}
[/php]
In case you wonder why I chose to add support for menus only after checking if register_nav_menus() is defined, it’s simply because there’s no point in adding support for a feature that you won’t be able to use. Remember, add_theme_support() was added in 2.9, while register_nav_menus() became available only in 3.0.
But how about adding compatibility in the front-end of your theme?
When using post thumbnails, never call them without checking if the function exists first:
[php]
// Performs a check to see if the function is available and there’s also a thumbnail attached
if (function_exists(the_post_thumbnail) AND has_post_thumbnail()) {
the_post_thumbnail();
}
[/php]
For the custom menus, the thing is just a tad trickier, but simple as well. I’m usually using a function that I wrote to specifically check for custom menus support, and even though the wp_nav_menu() function provides a fallback solution, defaulted to wp_page_menu(), this fallback will only activate for 3.0 installations without any menus created and allocated to the reserved space. The fallback won’t set off if you’re using a version prior to 3.0.
Due to my preference of wp_list_pages() over wp_page_menu() – for more customization options – the following function will apply a compatibility fallback to wp_list_pages:
[php]
function my_nav_menu() {
// Check if installation has wp_nav_menu() defined.
// If true, generate the menu, but don’t print it yet;
if(function_exists(wp_nav_menu)) {
$my_nav_menu = wp_nav_menu(array(‘menu’ => ‘Top Menu’, ‘container’ => ”, ‘fallback_cb’ => ‘wp_list_pages’, ‘depth’ => 2, ‘echo’ => false));
}
// If false, generate the menu using wp_list_pages, but don’t print it yet;
else {
$my_nav_menu = ‘
‘;
}
// Prints out the menu;
echo $my_nav_menu;
}
[/php]
Now, in the front end. instead of calling your menu with wp_nav_menu() you’ll now use my_nav_menu() to display a backward compatible version.
Conclusions
Caught in the rush of doing something nice and new, like a child discovering a shiny new toy, we can miss out some of the most basic problems. Most of them are really easy to solve, like the above mentioned and it would be common sense to make use of them.
And remember: if ( function_exists(function_name) ) is your geeky B.F.F.